Возможность создания внешнего PSC появилась в версии vSphere 6.0, а еще в vSphere 5.1 компания VMware предоставила возможность размещать отдельные компоненты, такие как VMware Update Manager (VUM) или vCenter Server Database (VCDB) на отдельных серверах. Это привело к тому, что средства управления виртуальной инфраструктурой можно было развернуть аж на 6 серверах, что рождало проблемы интеграции, обновления и сложности обслуживания.
Когда VMware предложила модель с внешним PSC инфраструктура свелась всего к двум узлам сервисов vCenter. PSC обслуживает инфраструктуру SSO (Single Sign-On), а также службы лицензирования, тэгов и категорий, глобальных прав доступа и кастомных ролей. Помимо этого PSC отвечает за сертификаты данного SSO-домена.
В то время, как службы PSC принесли гибкость развертывания, они же принесли и сложность обслуживания, так как для них нужно было обеспечивать отдельную от vCenter процедуру отказоустойчивости в инфраструктуре распределенных компонентов vCenter Enhanced Linked Mode (ELM).
Еще в vSphere 6.7 и vSphere 6.5 Update 2 была введена поддержка режима ELM для Embedded PSC, поэтому с внедренным PSC уже не требуется обеспечивать отказоустойчивость дополнительных узлов, балансировку нагрузки, а также их обновление. Теперь можно обеспечивать доступность узлов vCenter посредством технологии vCenter High Availability.
Поэтому уже сейчас можете использовать vCenter Server Converge Tool для миграции внешних PSC на Embedded PSC виртуального модуля vCenter Server Appliance. А возможности развернуть внешние PSC в следующих версиях vSphere уже не будет.
Таги: VMware, vSphere, HA, vCenter, PSC, Update, vCSA
Знаете ли вы, кто залогинен в ваши виртуальные машины? Сколько из этих учётных записей локальные и сколько доменные? Уверены ли вы, что знаете где именно в вашей виртуальной инфраструктуре определённый пользователь залогинен в данный момент? И наконец последний вопрос, хотите ли знать ответы на эти вопросы? Если ваш ответ «Да», эта статья вам будет очень полезна...
Многие администраторы VMware vSphere весьма консервативны и подолгу не обновляют версию платформы виртуализации, даже когда есть деньги на продление поддержки. Отчасти это верная стратегия - VMware так часто пропускает серьезные баги в мажорных релизах, что многие ждут пока обновление "настоится".
Но долго ждать тоже не стоит, так как можно недополучить преимущества новых версий. Например, всегда от релиза к релизу у платформы vSphere растет производительность в различных аспектах. В частности, давайте посмотрим, как выросла производительность технологии миграции хранилищ Storage DRS в VMware vSphere 6.7 по сравнению с версией 6.5.
VMware провела тестирование двух версий платформы и посмотрела, как быстро происходит генерация рекомендаций DRS в разрезе следующих операций в кластере:
CreateVM
CloneVM
ReconfigureVM (добавление дополнительного диска)
RelocateVM (перемещение на другой датастор)
Datastore Enter Maintenance (перевод датастора в режим обслуживания)
При одновременном исполнении в кластере множества данных задач одновременно имеет значение своевременное формирование рекомендаций (куда поместить ВМ, куда ее клонировать и т.п.). По итогам тестирования были получены следующие результаты (столбики показывают процент улучшения по времени для 5 одновременных исполняемых операций):
Для 16 одновременных операций:
Отдельно представлен график для операций Datastore Enter Maintenance:
Все это приводит к увеличению скорости развертывания и миграции виртуальных машин и их VMDK-дисков в больших инфраструктурах, где в этом участвует механизм SDRS (генерация рекомендаций по размещению виртуальных машин).
Уважаемые читатели! Некоторые из вас знают, что у нас на сайте есть цикл статей от Романа Гельмана, который разрабатывает различные функции своего PowerCLI-модуля Vi-Module. Они позволяют управлять многими аспектами виртуальной инфраструктуры VMware vSphere с помощью механизмов, недоступных в рамках стандартных средств управления.
Недавно Роман подал свой англоязычный блог ps1code.com на голосование по выбору лучшего блога о виртуализации Top vBlog 2018. И мы от лица всей редакции очень просим проголосовать за Романа - ведь его блог этого действительно достоин!
Спасибо вам заранее.
И вот статьи Романа на нашем ресурсе, чтобы вам удобнее было найти нужную функцию:
Несколько недель назад компания Login VSI, известная своими бенчмарками для виртуальных сред, выпустила обновленную версию своего средства для генерации и тестирования нагрузки приложений в виртуальных ПК - Login PI Release 3. Напомним, что о прошлой версии этого продукта мы писали вот тут.
На наш взгляд, это наиболее продвинутое средство тестирования производительности приложений в виртуальных десктопах на сегодняшний день.
Давайте посмотрим, что нового появилось в Login PI Release 3:
1. Технология Deep Application Performance Testing.
Она позволяет строить расширенные рабочие процессы с помощью логических условных выражений, что позволяет настроить нагрузку в соответствии с требованиями реальных производственных окружений. Сами приложения могут быть добавлены без использования скриптов.
Воркфлоу можно создавать с помощью функций автодополнения (intellisense) и подсветки синтаксиса. Их можно редактировать без соединения с бэкендом Login PI, то есть на клиенте без задержек.
Более гранулярные действия в рабочих процессах и возможность более детального планирования событий, что позволяет точнее настраивать симулированных пользователей и удобнее оркестрировать их поведение.
Расширенная поддержка сторонних приложений (EPIC, Cerner, AllScripts и т.п.), приложений пользователей (Microsoft Office), а также тесно интегрированных сторонних плагинов, рабочих процессов и скриптов.
2. Новая архитектура Login PI Release 3.
Здесь появились следующие улучшения:
Теперь поставляется как виртуальный модуль (virtual appliance) и развертывается за несколько минут.
За счет использования REST API теперь можно интегрировать Login PI с традиционными решениями для мониторинга, такими как SCOM, или системами управления инцидентами, например, ServiceNow, а также big-data анализаторами (например, Splunk).
Login PI R3 поддерживает соединения через RDP, PCoIP, Blast Extreme, Citrix ICA/HDX, NetScaler и любые другие.
Повышенная безопасность продукта.
3. Новый интерфейс.
В продукте были улучшены все дэшборды, которые теперь предоставляют более детальную информацию, дают ее более удобном для понимания виде для технического и бизнес-ориентированного персонала.
Новый интерфейс для конфигурации, репортинга и быстрых выводов (quick insights) в плане производительности.
Более детальная информация и умная агрегация данных на высокоуровневых дэшбордах для проверки и анализа нескольких серверных ферм в разных локациях, а также для нескольких клиентов (удобно для сервис-провайдеров).
4. Проактивный мониторинг.
С помощью функций проактивного мониторинга можно наблюдать за производительностью VDI-инфраструктуры и выявлять потенциальные проблемы еще до их возникновения. Это делается за счет определения метрик производительности на симулированных пользователях при условиях, которые возникнут в будущем.
Скачать пробную версию Login PI Release 3 можно по этой ссылке.
Некоторое время назад мы рассказывали об анонсах конференции VMworld Europe 2018, одним из которых была покупка компании Heptio, предоставляющая решения для управления контейнерами платформы Kubernetes в облаке. Ну а на днях на сайте проекта VMware Labs появился плагин к vSphere Client, который позволяет видеть кластеры и узлы Kubernetes, которые находятся под управлением Pivotal Container Service - vSphere PKS Plugin.
Возможности плагина PKS:
Визуализация, настройка и управление кластерами Kubernetes, развернутыми и управлеяемыми с помощью PKS.
Средства просмотра нижележащей инфраструктуры для контейнеров, включая виртуальные машины, сетевые ресурсы и объекты хранилищ, которые созданы в кластере Kubernetes, развернутом в окружении VMware vSphere.
Единая точка просмотра компонентов кластера Kubernetes, включая узлы и сетевые объекты, такие как роутеры, логические коммутаторы и балансировщики.
Простой интерфейс для доступа к кластеру через kubectl и дэшборд.
Для работы плагина вам понадобятся следующие компоненты:
PKS v1.2.x
NSX-T v2.3
vSphere v6.7.x, v6.5 U1, U2
Загрузить vSphere PKS Plugin можно по этой ссылке (там же вы найдете и документацию).
Компания VMware выпустила документ, касающийся работы баз данных Oracle Database 12c на платформе VMware vSAN - Oracle Database on VMware vSAN 6.7. Основная тема дока - тестирование числа операций ввода-вывода (IOPS) и latency операций СУБД на хостах в All-Flash конфигурации, когда и ярус кэширования, и ярус хранения реализован на SSD-дисках:
В документе рассматривается 4 ключевых аспекта для реализации тяжелых баз данных:
Производительность OLTP-нагрузок в кластере all-flash vSAN.
Политики Storage Policy Based Management (SPBM) для управления хранилищами.
Построение платформы для бизнес-критичных задач уровня Tier-1.
Валидация архитектуры для уменьшения времени развертывания и операционных рисков.
Для тестирования использовались хосты ESXi в следующей конфигурации:
В тестах использовалось два типа рабочих нагрузок (R1 и R15), отличающихся конфигурацией ВМ, а также включенными или выключенными технологиями дедупликации и компрессии на стороне vSAN:
Описание рабочей нагрузки:
Базовые результаты по IOPS и latency для операций чтения и записи:
После результатов тестирования в документе есть секция с рекомендациями по исполнению Oracle на хранилищах vSAN, которые будет полезно почитать администратору БД и vSphere (большая их часть приведена в vSAN Design and Sizing Guide).
Мы много писали о рещениях NVIDIA GRID / Quadro vDWS (они используют технологии virtual GPU или vGPU), например здесь, здесь и здесь. Ранее эта технология предполагала только применение vGPU для нагрузок в виртуальных машинах, которые требовательны к графике, поэтому используют ресурсы графического адаптера в разделенном режиме.
Между тем, начиная с недавнего времени (а именно с выпуска архитектуры Pascal GPU), VMware и NVIDIA предлагают использование vGPU для задач машинного обучения (CUDA / Machine Learning / Deep Learning), которые в последнее время становятся все более актуальными, особенно для крупных компаний. С помощью этой технологии виртуальная машина с vGPU на борту может эффективно использовать библиотеки TensorFlow, Keras, Caffe, Theano, Torch и прочие.
Например, можно создать использовать профиль P40-1q vGPU для архитектуры Pascal P40 GPU, что позволит иметь до 24 виртуальных машин на одном физическом адаптере (поскольку на устройстве 24 ГБ видеопамяти).
Зачем же использовать vGPU для ML/DL-задач, ведь при исполнении тяжелой нагрузки (например, тренировка сложной нейронной сети) загружается все устройство? Дело в том, что пользователи не используют на своих машинах 100% времени на исполнение ML/DL-задач. Большинство времени они собирают данные и подготавливают их, а после исполнения задачи интерпретируют результаты и составляют отчеты. Соответственно, лишь часть времени идет большая нагрузка на GPU от одного или нескольких пользователей. В этом случае использование vGPU дает максимальный эффект.
Например, у нас есть 3 виртуальных машины, при этом тяжелая нагрузка у VM1 и VM2 пересекается только 25% времени. Нагрузка VM3 не пересекается с VM1 и VM2 во времени:
Компания VMware проводила тест для такого случая, используя виртуальные машины CentOS с профилями P40-1q vGPU, которые имели 12 vCPU, 60 ГБ памяти и 96 ГБ диска. Там запускались задачи обучения TensorFlow, включая комплексное моделирование для рекуррентной нейронной сети (recurrent neural network, RNN), а также задача распознавания рукописного текста с помощью сверточной нейронной сети (convolution neural network, CNN). Эксперимент проводился на серверах Dell PowerEdge R740 с 18-ядерным процессором Intel Xeon Gold 6140 и карточками NVIDIA Pascal P40 GPU.
Результаты для первого теста оказались таковы:
Время обучения из-за наложения окон нагрузки в среднем увеличилось на 16-23%, что в целом приемлемо для пользователей, разделяющих ресурсы на одном сервере. Для второго теста было получено что-то подобное:
Интересен тест, когда все нагрузки исполнялись в одном временном окне по следующей схеме:
Несмотря на то, что число загруженных ML/DL-нагрузкой виртуальных машин увеличилось до 24, время тренировки нейронной сети увеличилось лишь в 17 раз, то есть даже в случае полного наложения временных окон рабочих нагрузок есть некоторый позитивный эффект:
Интересны также результаты с изменением политики использования vGPU. Некоторые знают, что у планировщика vGPU есть три режима работы:
Best Effort (это исполнение задач на вычислительных ядрах по алгоритму round-robin).
Equal Share (всем дается одинаковое количество времени GPU - это позволяет избежать влияния тяжелых нагрузок на легкие машины, например).
Fixed Share (планировщик дает фиксированное время GPU на основе профиля нагрузки vGPU).
VMware поэкспериментировала с настройками Best Effort и Equal Share для тех же тестов, и вот что получилось:
С точки зрения времени исполнения задач, настройка Best Effort оказалась лучшим выбором, а вот с точки зрения использования GPU - Equal Sharing меньше грузила графический процессор:
Как многие из вас знают, VMware vCenter для Windows версии 6.7 (на данный момент Update 1) - это последний vCenter, который еще доступен как отдельный продукт для Windows-машины. Следующая версия vCenter будет поставляться только как виртуальный модуль vCenter Server Appliance на базе Photon OS от VMware.
Мы уже писали о некоторых аспектах миграции на vCSA с vCenter for Windows, но в этом посте дадим несколько новых деталей по этому процессу. VMware рекомендует выполнить 2 основных шага миграции с vCenter на vCSA:
Migration Assistant - консольная утилита, которую нужно выполнить до мастера миграции vCenter. Она выясняет соответствие требованиям к миграции и показывает дальнейшие шаги.
Migration Tool - это мастер миграции, который доступен из основного дистрибутива vCenter.
Полный обзор процесса миграции показан в видео ниже:
Обратите внимание, что во время миграции вы можете выбрать опцию импорта исторических данных из старой копии vCenter for Windows в созданную новую копию vCSA (это опциональный процесс во время миграции, и можно сделать импорт уже позднее).
Migration Tool делает импорт всех скопированных данных в развернутый виртуальный модуль vCSA (включая параметры идентификации vCenter, такие как FQDN, IP-адрес, UUID, сертификаты, MoRef IDs и прочее). Также происходит миграция и vSphere Distributed Switch (vDS).
Надо отметить, что в процессе миграции не происходит никаких изменений в исходном vCenter, поэтому откат в случае неудачного обновления прост - останавливаете vCSA и продолжаете использовать vCenter Server for Windows.
Помимо всего этого есть утилита vCenter Server Converge Tool (о ней мы писали тут и тут), которая позволяет смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC. Проблема заключалась в том, что ранее администраторы использовали внешний PSC, поскольку он поддерживал Enhanced Linked Mode (ELM). И несмотря на то, что внедренный PSC стал поддерживать ELM еще в vSphere 6.7 и vSphere 6.5 Update 2, многие пользователи еще с предыдущих версий поддерживают комплексную инфраструктуру внешних PSC с репликацией между площадками.
Сейчас все стало проще - утилита vCenter Server Converge Tool устанавливает embedded PSC на vCenter Server Appliance (vCSA), после чего налаживает канал репликации с оставшимися внешними PSC. После того, как эта процедура пройдет на всех площадках, вы сможете отключить внешние PSC, а встроенный механизм vCenter HA сам настроится на работу с внедренными PSC.
Пройтись по шагам различных вариантов миграции vCenter и его PSC (встроенного или внешнего) можно вот в этих обучающих материалах VMware (там вы все это можете прокликать прямо в интерфейсе):
Кстати, надо понимать, что процесс миграции vCenter - это одновременно и его апгрейд. То есть вы можете, например, провести миграцию-апгрейд vCenter Server 6.0 на VCSA версии 6.7.
Ну и помните, что весь самый новый функционал есть только в VMware vCSA, который является рекомендуемым вариантом развертывания по умолчанию. Вам уже давно пора перейти на vCSA, если вы все еще пользуетесь vCenter для Windows.
Вчера мы написали о части того нового, что было представлено на конференции VMworld 2018, проходившей на днях в Барселоне, а сегодня расскажем об оставшихся анонсах.
Проект Dimension был представлен еще на VMworld 2018 в США, а сейчас VMware сделала доступной его бета-версию. Напомним, что это специальный сервис VMware по поставке, развертыванию, обслуживанию и сопровождению виртуальных датацентров.
VMware планирует договориться с вендорами аппаратного обеспечения таким образом, чтобы они поставляли оборудование, которое способно сразу после включения соединиться с облачными ресурсами VMware и обеспечить развертывание онпремизной инфраструктуры в рамках концепции Software-defined Datacenter (SDDC) на площадке заказчика.
Бета-версия будет доступна только отобранным VMware заказчикам, если у вас есть интерес принять участие - заполните форму вот тут.
2. Доступность Pivotal Container Service (PKS) как облачного сервиса и покупка Heptio.
На VMworld Europe 2018 компания VMware объявила о том, что этот сервис теперь станет облачным (VMware Cloud PKS), что позволит организовать управление гибридными средами Kubernetes в онпремизных и публичных облаках из единой точки.
Кроме того, на VMworld было объявлено о покупке компании Heptio, которая была основана создателями Kubernetes. Она предоставляет набор продуктов и профессиональных сервисов для управления контейнерами Kubernetes в онпремизных, публичных и гибридных облачных средах. Помимо управления контейнерами, решения Heptio предоставляют такие сервисы, как оркестрация приложений, поддержка жизненного цикла (развертывание, хэлсчек) и обеспечение доступности (снапшоты, резервное копирование).
Все продукты и технологии Heptio планируется включить в портфолио решений PKS и предоставлять контейнеры как услугу из облака (Kubernetes-as-a-Service).
3. Закрытая бета-программа для сервиса VMware Blockchain.
Мы уже затрагивали функциональность и развертывание блокчейн-платформы VMware. Blockchain на vSphere или BoV — это инструмент для развертывания Hyperledger Fabric v1.0 на платформе vSphere, или, другими словами, проект VMware, который помогает администраторам развернуть блокчейн-платформу для разработчиков на базе гипервизора ESXi.
Теперь блокчейн от VMware будет предоставляться как SaaS-платформа, которую предприятия смогут использовать из облака. При этом можно будет ограничивать пользователей данной платформы (permissioned blockchain system).
VMware Enterprise Blockchain уже используется в нескольких крупных компаниях, таких как Dell Technologies и Deloitte, для решения бизнес-задач. Участие в программе осуществляется только по приглашениям от VMware.
4. Возможность запуска ESXi на Raspberry PI (прототип).
На конференции был представлен прототип гипервизора для архитектуры компьютеров Raspberry PI. Это дает возможность для внедрения гипервизора VMware в сфере IoT (интернет вещей) на базе архитектуры ARM.
5. Улучшения Workspace One.
В ближайшее время будут представлены следующие улучшения решения Workspace ONE:
Продукт Workspace ONE Intelligence Automation Connector, который позволяет предоставлять аналитику и возможность управления и обновления различных сторонних программных и аппаратных компонентов. Это уже реализовано для приложений Slack и ServiceNow.
Сенсоры Workspace ONE Sensors для платформы macOS, которые дают информацию о состоянии программных и аппаратных компонентов настольных устройств Apple.
Решение Dell Provisioning for VMware Workspace ONE, которое позволяет произвести фабричную преконфигурацию устройств для дальнейшего управления ими в корпоративной инфраструктуре.
6. Улучшения Horizon 7 on VMware Cloud on AWS.
Тут обещают 2 основных улучшения:
Доступность сервисов Horizon 7 (VDI и RDSH, Full Clones и Instant Clones), а также продукта App Volumes на платформе VMware Cloud on AWS с предстоящими релизами Horizon 7.7 и App Volumes 2.15.
Интеграция онпремизного решения Horizon 7 с облаком VMware Cloud on AWS средствами Horizon Cloud Service. Это позволит упростить управление инфраструктурами с несколькими площадками и гибридными средами.
На этом все, информацию по остальным анонсам можно получить здесь.
Теперь утилита имеет поддержку инсталляций с режимом Enhanced Linked Mode для серверов Embedded vCenter Server платформ vSphere 6.5 Update 2 и vSphere 6.7, а также позволяет спланировать миграцию на них с версий vSphere 6.0 и 6.5.
Эта утилита работает полностью онлайн, спрашивает вас всего несколько вопросов, таких как новая ли это инсталляция или апгрейд, нужны ли вам фичи наподобие Enhanced Linked Mode и vCenter HA и прочее, а в результате выдает рекомендации по развертыванию или обновлению с описанием наиболее важных деталей, а внизу приводятся ссылки на необходимую документацию, блоги и базу знаний VMware.
Получить доступ к vSphere 6.7 Topology and Upgrade Planning Tool можно по этой ссылке.
P.S. Кстати, обратите внимание, что ресурс vSphere Central тоже обновился за последнее время.
Не все администраторы платформы виртуализации VMware vSphere знают, что такое Network I/O Control (NIOC). Причина проста - функции механизма регулирования полосы пропускания NIOC для различных видов трафика на стороне vSphere Distributed Switch (vDS) есть только в издании vSphere Enterprise Plus, которое, как правило, приобретают большие и средние компании.
Давайте посмотрим, что такое NIOC и разберем эту функциональность на примерах. Прежде всего, функция NIOC появилась тогда, когда с появлением сетей 10G стало понятно, что можно делать сетевую инфраструктуру на хостах ESXi с небольшим числом сетевых адаптеров, обладающих высокой пропускной способностью. Но в этих условиях также стало ясно, что сетевой трафик, идущий по таким сетям, надо в рамках того же 10G-канала как-то разграничивать.
NIOC позволяет системным и сетевым администраторам настраивать приоритизацию следующих видов трафика для пула сетевых адаптеров хостов ESXi:
Fault tolerance traffic
iSCSI traffic
vMotion traffic
Management traffic
vSphere Replication traffic
Network file system (NFS) traffic
Virtual machine (VM) traffic
User-defined traffic
Механизм NIOC появился еще в 2010 году в VMware vSphere 4.1, и с тех пор был очень сильно доработан (сейчас в vSphere 6.7 Update 1 доступна третья версия NIOC v3).
В интерфейсе HTML5-клиента vSphere Client эти настройки выглядят так (новый клиент полностью поддерживает рабочие процессы NIOC):
В vSphere Web Client вы можете увидеть эти настройки по адресу vDS > Manage > Resource Allocation > System traffic:
Механизм NIOC включен по умолчанию (для vSphere 6.0 и выше), но для типов трафика не заданы никакие ограничения (Limit) и резервации (Reservation) - только приоритеты между типами трафика (Shares). Работают эти 3 техники регулирования типа трафика так же, как и аналогичные механизмы для хранилищ или вычислительных ресурсов:
Reservation - гарантирует тому или иному типу трафика пропускную способность канала в Мбит/с. Важно помнить, что эта ширина канала резервируется, но в случае ее простоя ее смогут использовать другие типы системного трафика. Между тем, простой канала зарезервированного системного трафика не дает возможность распределить полосу на виртуальные машины. В любом случае, Reservation (если он вам очень нужен) нужно выставлять таким, чтобы обеспечить только минимальные запросы сервиса для его функционирования, а не средние и максимальные.
Limit - ограничивает сверху используемый канал для выбранного типа трафика.
Shares - с помощью чисел приоритета (от 1 до 100) позволяет выделить группы которые будут получать больше или меньше пропускной способности канала (например, если одна группа имеет 100, а другая 50 - то первая будет получать в два раза больше на фоне распределения всего трафика адаптеров по группам). Механизм этот начинает распределять канал после раздачи всех заданных резерваций.
Есть еще один нюанс - только 75% совокупной ширины канала на хосте ESXi может быть зарезервировано (а если говорить точнее - от адаптера с самой низкой пропускной способностью в этой группе на хосте). Остальные 25% остаются на всякий случай (например, компенсация всплесков управляющего трафика). Все, что не распределено с помощью Reservation, будет регулироваться средствами механизма Shares.
Для изменения резервации, лимита или shares категорий системного трафика надо открыть настройки конкретного типа трафика:
Для удобства Shares можно указывать не цифрами, а выбрать из комбо-бокса один из вариантов - Low (25), Normal (50) и High (100). В этом случае цифры для Shares автоматически подберутся (они указаны в скобках), чтобы составлять верные соотношения согласно выставленным приоритетам. После выставления этих параметров они будут применены на всех физических адаптерах хостов ESXi, подключенных к распределенному коммутатору vDS на сервере vCenter.
Когда вы задаете Reservation, максимальная пропускная способность для данного типа трафика будет равна этому значению, умноженному на число физических адаптеров на хостах, выделенных для этого типа трафика.
NIOC v3 также позволяет сконфигурировать резервации как на уровне отдельных виртуальных машин (в свойствах адаптера), так и создавать собственные пользовательские пулы (User-Defined Network Resource Pools), которые являются подмножеством корневого пула
Virtual machine (VM) traffic.
Для User-Defined Network Resource Pools выставление лимитов и Shares не предусмотрено - только Reservation.
В свойствах адаптера vNIC резервации на уровне отдельной ВМ можно выставить в ее настройках (это только гарантированная полоса, но машина может использовать и больше, если есть доступные ресурсы):
Если вы выставляете Reservation для адаптеров виртуальных машин, то их суммарная резервация не может быть больше, чем резервация для VM system traffic на этом хосте:
Если нужно настроить сетевые пулы ресурсов для групп виртуальных машин, то нужно создать новый пул в Web Client:
А потом указать резервацию для него:
Потом этот пул нужно указать при настройке распределенной группы портов на распределенном коммутаторе vDS:
Ну а к этой распределенной группе портов нужно уже подключить виртуальные машины, которые на всех получат эту резервацию.
При этом если вы задали резервацию 1 Мбит/с, а физических адаптеров на хосте ESXi у вас 5, то такая распределенная группа портов получит до 5 Мбит/с на свои виртуальные машины.
В итоге картина выглядит подобным образом:
Когда вы создадите новый пул в разделе Network Resource Pools, вы сможете посмотреть список виртуальных машин в нем на вкладке Virtual Machines:
Ну и напоследок отметим, что лимиты для сетевых адаптеров машин должны согласовываться с лимитами политики traffic shaping для распределенной группы портов, куда они воткнуты. Например, если для адаптера выставлен лимит 200 Мбит/с, а для всей порт-группы на vDS только 100 Мбит/с, то эффективным ограничением будет именно 100 Мбит/с.
На прошедшей в конце лета конференции VMworld 2018 компания VMware сделала несколько интерсных анонсов для сервис-провайдеров, предоставляющих услуги аренды виртуальных машин по модели IaaS. Например, недавно мы писали о Cloud-to-Cloud Disaster Recovery 1.5, а сегодня расскажем про Cloud Provider Pod 1.0, который стал доступен для скачивания на днях.
Cloud Provider Pod - это решение, которое позволяет сервис-провайдерам, приступающим к инсталляции всех облачных компонентов спланировать будущий дизайн инфраструктуры публичного облака и провести развертывание всех сервисов SDDC (Software-Defined Data Center).
Cloud Provider Pod служит для выполнения трех задач:
Планирование и дизайн будущей архитектуры публичного облака (Pod Designer). Это онлайн-утилита на стороне VMware, которую можно использовать в двух режимах - упрощенном (только тип хранилищ, зоны доступности, сайзинг, число хостов и т.п.) и расширенном (полный комплект сетевых настроек, планирование ресурсов и управление лицензиями). Результатом работы Pod Designer является пакет с будущей конфигурацией облака, который выгружается для сервис-провайдера
Развертывание компонентов SDDC (Pod Deployer) и их конфигурация с учетом созданного дизайна с помощью мастера. Эта штука уже скачивается с сайта VMware в виде готового виртуального модуля в формате OVA и далее исполняется уже на площадке сервис-провайдера, в нее и загружается созданный в дизайнере пакет конфигурации.
Генерирование документации с учетом конкретной специфики среды сервис-провайдера - на основе шаблонов VMware Validated Designs for Cloud Providers. Это проверенные лучшие практики VMware, в которые добавляются особенности вашей инфраструктуры.
На данный момент Cloud Pod заточен на развертывание и конфигурацию следующих программных компонентов виртуальной среды:
vSphere 6.5u2
vSAN 6.6.1
NSX 6.4.1
vCloud Director 9.1.0.1
vCloud Director Extender 1.0.1
vRealize Orchestrator 7.4
vRealize Operations 7.0
vRealize Log Insight 4.6.1
vRealize Network Insight 3.8
Usage Meter 3.6.1
Понятно, что версии этих решений не самые свежие, но VMware обещает обновлять Cloud Pod каждые полгода.
Основное назначение Cloud Provider Pod - дать сервис-провайдерам инструмент для построения своего облака на базе широкого спектра оборудования (см. User Guide по продукту) и решения VMware vCloud Director для управления облачной средой.
С помощью Cloud Provider Pod можно потенциально сэкономить месяцы работы системных администраторов за счет централизованного мастера настройки параметров виртуальной среды согласно созданному дизайну инфраструктуры (особенно это касается настроек сетевого окружения) и конфигурации управляющих и ресурсных кластеров, в которых будут работать машины клиентов.
Скачать VMware Cloud Provider Pod 1.0 в части Deployer можно по этой ссылке. Онлайн-сервис Designer находится тут.
Напомним, что VMFS-6 впервые появилась в VMware vSphere 6.5 и с тех пор сильно не изменялась, но если посмотреть на отличия шестой версии от пятой, то они весьма существенные:
Как мы видим, основных отличий четыре:
Доступ к хостам ESXi 6.0 и более ранних к VMFS-6 уже невозможен.
Последний пункт как раз и стал причиной того, что произошло изменение в структуре метаданных томов, а значит VMFS-5 нельзя проапгрейдить до VMFS-6. Альтернативой является создание нового датастора VMFS-6, перемещение туда всех виртуальных машин и удаление старого.
Создаем новый VMFS-6:
Перемещаем туда все виртуальные машины тома VMFS-5 через Storage vMotion или Cold migration и удаляем его:
Как стало понятно, для такого "апгрейда" датастора VMFS-5 вам потребуется еще столько же места на другом датасторе или готовом к форматированию под VMFS-6 хранилище, чтобы переместить туда виртуальные машины.
Чтобы посмотреть текущие версии VMFS с помощью PowerCLI, нужно выполнить команду:
Get-Datastore | Select Name, FileSystemVersion | Sort Name
Перед началом процесса апгрейда нужно ознакомиться со статьей KB "Migrating VMFS 5 datastore to VMFS 6 datastore". Для миграции надо использовать командлет Update-VmfsDatastore, который также делает некоторые проверки перед миграцией.
При этом надо учитывать несколько моментов:
На время миграции нужен датастор VMFS-5 такой же или большей свободной емкости.
Машины перемещаются средствами Storage vMotion на временное хранилище.
Командлет убеждается, что на датасторе не осталось ВМ, миграция которых не поддерживается (это машины с поддержкой SRM, VADP, VRM и Clustering).
Командлет временно отключает механизм Storage DRS при своей работе (и включает по окончании). Если сценарий во время исполнения упадет, то вам придется включать Storage DRS вручную.
Нужно внимательно изучить использование параметров Resume и Rollback в случае появления ошибок.
Посмотрим, какие последовательные действия делает сценарий:
Проверяет наличие ВМ с поддержкой VADP, SMPFT, MSCS/RAC на исходном датасторе.
Убеждается, что датастор доступен со всех хостов.
Валидирует, что временный датастор имеет достаточно емкости для размещения виртуальных машин.
Устанавливает функцию Storage DRS Automation в режим manual.
Размонтирует исходный датастор.
Удаляет старый датастор и создает на его месте новый датастор VMFS-6.
Перемещает ВМ и другие данные со временного датастора на новый.
Восстанавливает настройку Storage DRS Automation.
Теперь, собственно, как использовать командлет Update-VmfsDatastore:
Если у вас что-то пошло не так, вы сможете использовать параметр rollback для отката, а также если возникают ошибки, то после их исправления можно использовать параметр resume.
Больше об использовании командлета Update-VmfsDatastore написано вот тут.
Многие из вас пользуются лабораторными работами VMware Hands-on Labs, которые позволяют освоить работу с различными продуктами и технологиями, проходя по шагам интерфейса. Но это подходит только для целей обучения работе в интерфейсе этих решений, а если хочется полноценно запустить какой-нибудь продукт (например, vSAN, NSX или PKS) в реальных условиях и посмотреть на его производительность - то для этого есть портал VMware TestDrive, о котором недавно написал Дункан Эппинг.
Преимущество данного сервиса в том, что инфраструктура в нем построена на базе референсной архитектуры VMware, на сертифицированном оборудовании, а среда настроена таким образом, что позволяет оценить реальную нагрузку на аппаратные компоненты (сеть, хранилища, процессор/память).
TestDrive работает в облаке Softlayer от IBM и доступен во всех глобальных регионах по миру (US, EMEA, APJ). При этом, работая с инфраструктурой, вы можете делать множество интересных вещей под аккаунтом SuperUser, свободу сильно не ограничивают, за исключением удаления объектов. VMware говорит, что TestDrive в этом году использовали уже 344 тысячи раз.
По окончании тестирования партнер VMware может посмотреть его результаты и обсудить их с клиентом:
Чтобы партнерам VMware использовать данный сервис, им нужна компетенция VTSP HCI, после чего TestDrive будет доступен через Partner Central. Для начала получения компетенции зайдите в Partner University и подпишитесь на аккредитацию Hyper-Converged Infrastructure accreditation:
Одно из самых интересных на портале - возможность тестирования кластеров хранилищ vSAN (на данный момент это vSAN 6.7, но скоро окружение будет обновлено до vSAN 6.7 Update 1). Там доступно управление виртуальной инфраструктурой десктопов Horizon и машинами, а также есть доступ к средству тестирования нагрузки HCIBench. С помощью решений vSAN Health and Performance Service и vROPs можно замерять задержки (latency) и число операций ввода-вывода в секунду (IOPS) в различных условиях эксплуатации виртуальных машин:
Надо понимать, что в качестве аппаратной среды используется All-Flash конфигурация хостов, поэтому все работает довольно шустро.
Для доступа к сервису нужно попросить его у своего поставщика, являющегося партнером VMware, который должен зарегистрироваться на портале vmtestdrive.com.
Бонус для дочитавших до этого места! Дункан выбил возможность всем желающим использовать VMware TestDrive в течение 30 дней, для этого надо зарегистрироваться с промо-кодом DUNCANYB или использовать вот эту ссылку.
Сотрудники компании VMware написали интересную серию статей об обновлении VMware vSphere, где одной из самых интересных оказалась статья про обновление VMware Tools через PowerCLI. Одновременно там рассматриваются и вопросы обновления виртуального железа ВМ.
Давайте посмотрим, как правильно выполнять эту процедуру. Прежде всего, помните: сначала надо обновить VMware Tools во всех ВМ и только после этого обновлять VM Hardware, а не наоборот!
Итак, давайте пройдем процедуру апгрейда VMware Tools с помощью фреймворка PowerCLI.
1. Если вы посмотрите в интерфейс vSphere Client, то увидите, что на вкладке Summary написана текущая версия VMware Tools а также приведена информация о том, нужен ли их апгрейд.
2. Чтобы увидеть, какие машины нуждаются в апгрейде, а какие имеют последние версии VMware Tools, нужно выполнить команду:
Неудобство здесь в том, что обновление VMware Tools на всех машинах происходит в одно время. Поэтому нужно загнать процесс в цикл, где в один момент будет обрабатываться одна машина:
ForEach ($VM in $OutOfDateVMs){Update-Tools -NoReboot -VM $VM.Name -Verbose}
Более подробную информацию об обновлении VMware Tools через PowerCLI можно получить здесь.
4. Также в настройках виртуальной машины можно поставить галку "Check and upgrade VMware Tools before each power on", которая позволит проверять обновления тулзов и накатывать их при каждой загрузке ВМ:
Запустим команду из п.5, чтобы убедиться, что настройка автоматического обновления выставлена:
7. Теперь настало время обновить VM Compatibility, то есть виртуальное аппаратное обеспечение виртуальной машины (Virtual Hardware). Для этого сначала проверим текущие его версии на всех виртуальных машинах командой:
Get-folder Testing | Get-VM | Select Name, Version | Sort Name
Помните, что апгрейд Virtual Hardware процедура очень ответственная, например, 14-я версия железа совместима только с vSphere 6.7. И перед каждым обновлением VM Hardware делайте снапшот виртуальной машины (он сохраняет конфигурацию виртуального железа), чтобы откатиться к тему в случае проблем гостевой ОС с новым виртуальным железом.
8. Для обновления Virtual Hardware, например, на машине VM08 используйте вот такой скрипт:
Это можно проделать только для выключенной виртуальной машины, и тут не бывает настройки автоматического обновления, так как это процедура ответственная и довольно редкая. Больше о функциях VM Compatibility вы можете прочитать здесь.
Один из наших читателей Сергей справедливо отметил, что мы обошли вниманием бесплатное решение SexiGraf, предназначенное для мониторинга виртуальной инфраструктуры VMware vSphere. Оно было сделано энтузиастами (Raphael Schitz и Frederic Martin) в качестве альтернативы платным продуктам для мониторинга серверов ESXi и виртуальных машин.
Представления SexiPanels для различных метрик в различных разрезах есть не только для VMware vSphere и vSAN, но и для ОС Windows и FreeNAS, но мы остановимся только на панелях для vSphere. Да и то, давайте посмотрим только на 17 самых интересных из них, поскольку различных фильтров, вариаций и комбинаций этих панелей и представлений очень много, все в одну статью не поместится.
SexiGraf представляет собой виртуальный модуль (Virtual Appliance) с веб-интерфейсом администрирования, который можно удобно настроить под себя. Давайте посмотрим, какие самые интересные представления есть в SexiGraf:
1. Полная статистика по одному или нескольким кластерам.
Кое-что здесь взято из раздела производительности vCenter, но большинство метрик отличаются и могут быть вам очень интересны:
2. Полная статистика по одному или нескольким серверам ESXi.
Это представление похоже на предыдущее, только статистика по датасторам и адаптерам vmnic не агрегируется и представляется отдельно:
3. Планирование емкости одного или нескольких кластеров.
Прикольная штука - задаете кластер (один или несколько), масштаб заполнения для процессорных ресурсов (scale) и получаете статистики по числу используемых виртуальных машин и сколько их еще можно в кластер вместить:
4. Использование процессоров и памяти.
Можно выбрать один или несколько кластеров, сравнить их между собой, а также представить агрегированные данные по всей инфраструктуре:
5. Хранилища по IOPS и Latency.
Можно вывести датасторы и сравнить их по числу операций в секунду (IOPS) и возникающей задержке:
6. Агрегированное заполнение ресурсов по кластерам.
Напомним, что сервис DRS Dump Insight - это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS. После этого будет выведена информация об операциях по перемещению виртуальных машин, которые рекомендует выполнить механизм балансировки нагрузки DRS:
Плагин DRS Dump Insight в вашем vCSA позволит ответить на следующие вопросы:
Где взять список всех рекомендаций DRS?
Почему DRS выдал конкретную рекомендацию (улучшить баланс по CPU, по памяти и т.п.)?
Почему DRS не вырабатывает рекомендации по балансировке кластера?
Как созданное пользователем правило affinity/anti-affinity влияет на балансировку ресурсов в кластере?
Если применить некоторую политику в кластере, как изменится балансировка ресурсов DRS?
При установке DRS Dump Insight H5 Plugin нужно выполнить следующие действия:
Проверить версию vCenter Server Appliance - подходит только 6.5 и 6.7.
Положить пакет с плагином в папку /usr/lib/vmware-vsphere-ui/plugin-packages/ на сервере vCSA.
Добавить настройку CompressDrmdumpFiles со значением "0" в advanced options кластера.
Перезапустить службу графического интерфейса vsphere-ui командами:
service-control --stop vsphere-ui
service-control --start vsphere-ui
После установки на вкладке Monitor для каждого кластера вы увидите раздел "DRS Dump Insight".
Загрузить DRS Dump Insight H5 Plugin можно по этой ссылке (в комбо-боксе выберите версию для своего vCenter).
Недавно компания VMware выпустила обновленную версию полезного постера vCloud Foundation Architecture Poster 3.0. Напомним, что о прошлой версии постера мы писали вот тут, а о самой инициативе vCloud Foundation (VCF) - тут.
Данная архитектура включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack и VMware Horizon в онпремизной или облачной инфраструктуре.
Этот релиз платформы VCF увеличил гибкость для заказчиков при выборе оборудования с поддержкой сетевых компонентов для решения NSX и готовых узлов кластеров хранилищ vSAN ReadyNodes. Так как архитектура VCF имеет в своем составе множество тесно интегрированных продуктов, этот постер поможет понять, как они взаимодействуют в рамках концепции программно-определяемого датацентра (Software-Defined Data Center, SDDC).
Первое нововведение в VCF, рассмотренное в постере - домены рабочих нагрузок (Workload Domains), состоящие из нескольких кластеров:
Каждый такой домен имеет собственный сервер vCenter и сетевой управляющий слой NSX manager, а также его контроллеры (NSX controllers). Одна из главных сфер применения этой технологии - выделение домена рабочей нагрузки под бизнес-единицу крупного предприятия (например, сектор ERP). Управление таким доменом можно делегировать администратору, а облачный администратор может управлять всеми доменами в режиме Enhanced link mode.
Также в постере рассматривается архитектура NSX Hybrid Connect, которая позволяет на уровне L2 объединить географически разделенные онпремизные облака.
NSX Hybrid Connect с помощью специального модуля создает Hybrid Mobility Tunnel, который прокладывает канал в существующую сеть. В этой гибридной среде доступны такие возможности, как vMotion, массовая миграция ВМ, High Throughput Network Extension, функции WAN optimization, Traffic Engineering, Load Balancing, Automated VPN with Strong encryption и средства восстановления после сбоев.
Скачать VMware vCloud Foundation Architecture Poster 3.0. можно по этой ссылке.
Не так давно мы писали про новые возможности решения для создания отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 1. Одной из новых возможностей этого продукта стала функция возвращения неиспользуемого гостевыми ОС дискового пространства в сторону физической дисковой подситсемы. Ранее эта возможность не работала, о чем мы писали вот тут.
Все понимают, что современные операционные системы стараются писать новые данные в новые пустые блоки, чтобы оставалась возможность восстановить старые, помеченные как удаленные. vSAN поддерживает технологию thin provisioning, что позволяет создавать хранилища растущие по мере наполнения данными. Но дело в том, что такие хранилища растут всегда, даже когда в гостевых системах освобождается место, что следует из первого предложения этого абзаца.
В этом случае очень бы хотелось это место вернуть опять как свободное на сторону дискового хранилища, так вот функции TRIM и UNMAP именно это и делают. vSAN 6.7 U1 теперь полностью обрабатывает SCSI/ATA-команды TRIM/UNMAP и автоматически возвращает дисковое пространство хранилищу. При этом, поскольку vSAN не использует тома LUN или VMFS, в рамках этой процедуры не требуется прохождения рабочего процесса через эти уровни абстракции.
Помимо очевидного преимущества очистки хранилища, процесс возвращения дисковых блоков имеет еще 3 позитивных эффекта:
Блоки, вышедшие из пространства vSAN, не нужно реплицировать между хостами и тратить на это ресурсы.
Эти блоки не надо обрабатывать со стороны систем резервного копирования.
Очистка грязных страниц из кэша на чтение, что уменьшает число копируемых блоков между кэшем и ярусом хранения (capacity tier).
VMware говорит, что в целом TRIM/UNMAP не влияет на производительность, но если происходит большое число команд UNMAP, то надо посматривать за производительностью.
Для включения этого механизма можно использовать команду:
vsan.unmap_support VSAN-Cluster -e
Windows Server 2012 и более поздние версии ОС поддерживают автоматическое возвращение дискового пространства. Чтобы проверить работу этой функции, надо выполнить команду:
Надо отметить, что процесс возвращения блоков происходит асинхронно, поэтому результат проявляется не сразу. Чтобы в Windows запустить TRIM для диска можно выполнить команду PowerShell:
PS C:\>Optimize-Volume -DriveLetter H -ReTrim -Verbose
Результат будет, например, таким:
Также TRIM можно сделать и с помощью утилиты дефрагментации, запустив ее с флагом /L:
Defrag C: D: /L
За производительностью процесса TRIM/UNMAP можно наблюдать в консоли vSAN, в разделе Monitor->vSAN->Performance.
Здесь два основных параметра на нижнем графике:
UNMAP Throughput - скорость прохождения команд UNMAP к дисковым группам хоста.
Recovery UNMAP Throughput - скорость прохождения команд UNMAP, которые выполняются как часть процесса object repair при отсутствующем или испорченном дисковом объекте.
Мы уже много писали о продуктах и технологиях, представленных на конференции VMworld 2018, которая прошла в августе этого года в Лас-Вегасе. Но самое интересное - это превью новых технологий и продуктов, ожидающих нас в ближайшем (и не очень) будущем.
Давайте посмотрим, что именно анонсировала в этом плане VMware:
1. Project Concord.
Это подход VMware к решению задачи византийских генералов (она же Byzantine fault tolerance, BFT). Она предполагает обеспечения функционирования распределенной системы, где важны вопросы доверия узлов друг другу (например, вредоносные реплики виртуальных машин) и подтверждения подлинности репликаций за счет обмена между узлами. Проект Concord обеспечивает работу этого протокола за счет получения конценсуса между входящими в его сеть распределенными узлами.
Да, тут есть связь с блокчейном и децентрализованными технологиями. Более подробно об этом проекте можно прочитать вот тут, а углубиться - вот тут.
2. Project Dimension.
Об этом проекте мы уже писали вот тут. Это специальный сервис VMware по поставке, развертыванию, обслуживанию и сопровождению виртуальных датацентров.
VMware планирует договориться с вендорами аппаратного обеспечения таким образом, чтобы они поставляли оборудование, которое способно сразу после включения соединиться с облачными ресурсами VMware и обеспечить развертывание онпремизной инфраструктуры в рамках концепции Software-defined Datacenter (SDDC) на площадке заказчика. Пока на эту тему подписались DellEMC и Lenovo.
3. Project Magna.
Проект Magna ставит своей целью создания автономного датацентра (self-driving data center), основанного на технологиях машинного обучения. Эти возможности частично будут основаны на технологиях купленной компании Cloud Health Technologies, занимающейся управлением публичными облачными инфраструктурами от различных вендоров.
Самое интересное, что VMware планирует внедрять Magna в продукты в тихом режиме и не афишировать их применение в том или ином решении. Хотя возможно для этого и будет специальный дэшборд в решении Wavefront.
4. Amazon RDS (Relational Database Service) on VMware.
Этот сервис позволит в перспективе переместить нагрузки реляционных баз данных под управлением RDS, таких как SQL Server, MySQL, Oracle, MariaDB или PostgreSQL в частное облако на платформу VMware vSphere. В этом случае частный датацентр будет подключен к гибридному облаку под управлением AWS с функциями disaster recovery, будет поддерживать резервное копирование Amazon S3 backup, а также полный стек технологий мониторинга через vRealize Operations.
Возможно, после этого на платформу vSphere переедут и другие сервисы Amazon, такие как SageMaker, Lex, Polly и Recognition.
5. Virtualization on 64-bit ARM for Edge
В рамках одной из сессий VMware рассказала о работе гипервизора ESXi на 64-битных процессорах архитектуры ARM. Это первый шаг VMware в экосистему IoT решений, где также потребуется запускать виртуальные машины для выполнения изолированных задач.
На этом пока все, но это еще не все новости с прошедшего VMworld. Приходите за обновлениями.
На завершившейся сейчас в Лас-Вегасе конференции VMworld 2018 компания VMware представила немало интересных анонсов, о которых мы расскажем в ближайшем будущем. Среди них одними из самых обсуждаемых стало объявление о выпуске vSphere 6.7 Update 1 и новое издание vSphere Platinum.
Давайте посмотрим, что такое vSphere Platinum, из чего состоит это решение, и для кого оно предназначено. Прежде всего, vSphere Platinum - это комбинация из двух продуктов: платформы VMware vSphere Enterprise Plus и решения VMware AppDefense.
Но это не просто сочетание двух продуктов, это еще и специальный плагин к vCenter для vSphere Client, который и реализует их сопряжение (называется он vCenter Server plugin for vSphere Platinum). Это дает доступ администраторам к функциональности AppDefense через стандартные средства управления платформой vSphere.
Суть технологии AppDefense заключается в том, что она изучает нормальное поведение операционной системы и приложений при обычных условиях, пользователь определяет это состояние как "нормальное", а в случае выявления отклонений от этого состояния, оповещает об этом администратора и автоматически предпринимает некоторые шаги по защите окружения.
Главный интерфейс AppDefense предназначен для администраторов безопасности, а вот плагин к vCenter для AppDefense больше нацелен на администраторов vSphere. Он позволяет сопоставить данные AppDefense, такие как процессы и угрозы, виртуальным машинам и сетям, в которых они актуальны.
Вот, например, представление для администратора безопасности в консоли AppDefense:
Здесь можно увидеть много всего интересного, но нет самого главного - к каким виртуальным машинам относится эта информация о приложениях.
Поэтому зайдем в дэшборд плагина vSphere Client к AppDefense, где можно увидеть эту информацию:
Здесь видны инфраструктурные объекты - хосты и виртуальные машины (вместо IP-адресов и портов в AppDefense). Поэтому администратор может разобраться с угрозами, относящимися к приложениями с помощью управления конфигурациями хостов и виртуальных машин.
Более того, администратор vSphere может зайти на вкладку Monitor, где в категории AppDefense получить список всех процессов внутри гостевой ОС и их состояний:
Таким образом, администратор vSphere может взаимодействовать с администратором безопасности, который работает с консолью AppDefense, в целях выявления и устранения угроз безопасности в виртуальной инфраструктуре. Кстати, сам плагин к vCenter доступен только если вы покупаете решение vSphere Platinum пакетом.
В итоге, vSphere Platinum содержит в себе следующие компоненты и технологии обеспечения безопасности:
Технология Secure Boot for ESXi – не позволяет посторонним компонентам работать на уровне гипервизора.
Secure Boot for Virtual Machines – предотвращает неавторизованное изменение виртуальных машин.
Поддержка модуля TPM 2.0 для ESXi – проверяет целостность гипервизора при загрузке и предоставляет функции удаленной аттестации хостов.
Устройства Virtual TPM 2.0 – дает функции безопасности для гостевых ОС, при этом все операционные возможности (например, vMotion или disaster recovery) остаются доступными.
Audit Quality Logging – предоставляет администраторам высокую степень детализации при анализе происходящих в vSphere операций.
Кстати, интересная фишка - при покупке лицензий vSphere Platinum для 5 процессоров или более, пользователи будут получать $10 000 на счет для использования публичного облака VMware Cloud on AWS. Это позволит опробовать технологии организации гибридного облака (подробнее об этой программе - тут).
О доступности для загрузки vSphere Platinum будет объявлено несколько позднее.
В последней версии платформы виртуализации VMware vSphere 6.7 появилась новая возможность - поддержка Persistent Memory (PMEM). Это новый вид памяти, который покрывает разрыв между оперативной памятью (RAM) и дисковой памятью (Flash/SSD) с точки зрения быстродействия и энергонезависимости.
PMEM имеет 3 ключевые характеристики:
Параметры задержки (latency) и пропускной способности (bandwidth) как у памяти DRAM (то есть примерно в 100 быстрее, чем SSD).
Процессор может использовать стандартные байт-адресуемые инструкции для сохранения данных и их подгрузки.
Сохранение значений в памяти при перезагрузках и неожиданных падениях устройства хранения.
Таким образом, память PMEM находится в следующем положении относительно других видов памяти:
А ее характеристики соотносятся с SSD и DRAM памятью следующим образом:
Такие характеристики памяти очень подойдут для приложений, которым требуется сверхбыстродействие, при этом есть большая необходимость сохранять данные в случае сбоя. Это могут быть, например, высоконагруженные базы данных, системы тяжелой аналитики, приложения реального времени и т.п.
На данный момент vSphere 6.7 поддерживает 2 типа решений PMEM, присутствующих на рынке:
NVDIMM-N от компаний DELL EMC и HPE - это тип устройств DIMM, которые содержат как DRAM, так и модули NAND-flash на одной планке. Данные передаются между двумя модулями при загрузке, выключении или любом событии, связанном с потерей питания. Эти димы поддерживаются питанием с материнской платы на случай отказа. Сейчас обе компании HPE и DELL EMC поставлют модули 16 GB NVDIMM-N.
Модули Scalable PMEM от компании HPE (доступно, например, в серверах DL380 Gen10) - они позволяют комбинировать модули HPE SmartMemory DIMM с устройствами хранения NVMe (интерфейс Non-volatile Memory дисков SSD) и батареями, что позволяет создавать логические устройства хранения NVDIMM. Данные передаются между DIMMs и дисками NVMe. Эта технология может быть использована для создания систем с большим объемом памяти PMEM на борту.
При этом накладные затраты на использование виртуализации с устройствами PMEM не превышают 3%. Вот так выглядят примерные численные характеристики производительности памяти NVMe SSD и NVDIMM-N по сравнению с традиционными дисками:
С точки зрения предоставления памяти PMEM виртуальной машине, есть 2 способа в vSphere 6.7:
vPMEMDisk - vSphere представляет PMEM как обычный диск, подключенный к виртуальной машине через контроллер SCSI. В этом случае ничего не нужно менять для гостевой ОС или приложений. В таком режиме работают любые системы, включая старые ОС и приложения.
vPMEM - vSphere представляет PMEM как устройство NVDIMM для виртуальной машины. Большинство последних версий операционных систем (например, Windows Server 2016 и CentOS 7.4) поддерживают устройства NVDIMM и могут предоставлять их приложениям как блочные или байт-адресуемые устройства. Приложения могут использовать vPMEM как устройство хранения через тонкий слой файловой системы direct-access (DAX), либо замапить регион с устройства и получать к нему прямой доступ через байтовую адресацию. Такой режим может быть использован старыми или новыми приложениями, но работающими в новых версиях ОС, при этом версия Virtual Hardware должна быть не ниже 14.
Вот так это выглядит с точки зрения логики работы:
Если у вас хост VMware ESXi имеет на борту устройства с поддержкой PMEM, вы можете увидеть это в его свойствах в разделе Persistent Memory:
При создании новой виртуальной машины вы сможете выбрать, какое хранилище использовать для нее - стандартное или PMem:
Параметры диска на базе PMEM можно установить в разделе Customize hardware:
Также в свойствах виртуальной машины можно добавить новый жесткий диск в режиме vPMEMDisk:
Если же вы хотите добавить хранилище в режиме vPMEM, то надо указать соответствующий объем использования устройства в разделе New NVDIMM:
Надо отметить, что хранилище PMEM может быть на хосте ESXi только одно и содержит только устройства NVDIMM и виртуальные диски машин (то есть вы не сможете хранить там файлы vmx, log, iso и прочие). Для такого датастора единственное доступное действие - это просмотр статистик (при этом в vSphere Client на базе HTML5 датасторы PMEM вообще не видны). Вывести статистику по устройствам PMEM можно командой:
# esxcli storage filesystem list
Пример результатов вывода:
При включении ВМ, использующей PMEM, создается резервация этого устройства, которая сохраняется вне зависимости от состояния виртуальной машины (включена она или выключена). Резервация очищается при миграции или удалении ВМ.
Что касается миграции ВМ с устройством PMEM, то особенности этой миграции зависят от режима использования машиной устройства. Для миграции между хостами ESXi машины с PMEM включается не только vMotion, но и Storage vMotion, а на целевом хосте должно быть достаточно места для создания резервации от мигрируемой машины. При этом машину с хранилищем в режиме vPMEMDisk можно перенести на хост без устройства PMEM, а вот машину с vPMEM - уже нет.
В самом плохом случае при миграции ВМ с хранилищем NVMe SSD ее простой составит всего полсекунды:
Технологии VMware DRS и DPM (Distributed Power Management) полностью поддерживают память PMEM, при этом механизм DRS никогда не смигрирует машину, использующую PMEM на хосте, на сервер без устройства PMEM.
vPMEM-aware - это использование устройства PMEM гостевой ОС, которая умеет работать с модулем PMEM на хосте через прямой доступ к постоянной памяти устройства.
2. Бенчмарк FIO для пропускной способности (Throughput):
3. Бенчмарк HammerDB для Oracle, тестирование числа операций в секунду:
4. Тест Sysbench для базы данных MySQL, тестирование пропускной способности в транзакциях в секунду:
Еще несколько интересных графиков и тестовых кейсов вы можете найти в документе, ссылка на который приведена выше. Ну а больше технической информации о PMEM вы можете почерпнуть из этого видео:
Документация на тему использования Persistent Memory в VMware vSphere 6.7 доступна тут и тут.
На днях компания VMware обновила свой PowerShell-фреймворк для управления виртуальной инфраструктурой, выпустив PowerCLI 10.2.0. Напомним, что о версии VMware PowerCLI 10.1.1 мы писали вот тут. Это уже четвертый релиз в этом году, самое значимое обновление - PowerCLI 10 - вышло в марте.
На самом деле, нового в PowerCLI 10.2 появилось не так уж и много:
Поддержка обновленной версии решения NSX-T 2.2 в модуле VMware.VimAutomation.Nsxt.
Вывод из эксплуатации модуля VMware.VimAutomation.PCloud (он еще доступен, но будет убран в будущем), ранее он управлял функциями vCloud Air.
Обновление функции Get-VIEvent, которое решает проблему с неожиданной ошибкой "Error in deserializing body of reply message for operation ‘RetrieveProperties’".
Компания VMware наконец-то обновила свой главный документ о производительности основной платформы виртуализации - "Performance Best Practices for VMware vSphere 6.7". Несколько ранее мы писали о документе "What’s New in Performance - VMware vSphere 6.7", в котором были рассмотрены основные нововведения последней версии продукта в плане производительности, но там было всего 13 страниц, а в этой книге о производительности - аж 88!
Само собой, книга покрывает аспекты не только новой функциональности vSphere 6.7, но и уже давно существующие фичи (с последними обновлениями, конечно). Вот о каких аспектах производительности платформы можно найти информацию в документе:
Hardware-assisted virtualization
Storage hardware considerations
Network hardware considerations
Memory page sharing
Getting the best performance with iSCSI and NFS storage
Штука эта, очевидно, обязательна к прочтению администраторам vSphere, которые хотят, чтобы у них в инфраструктуре все работало без сбоев и не тормозило.
Несколько интересных моментов из документа:
Начиная с версии vSphere 6.7, платформа больше не поддерживает программную виртуализацию CPU (только аппаратную).
vSphere Flash Read Cache (vFRC) может негативно влиять на производительность vMotion.
Для VVols массив сам обнуляет блоки перед созданием тома, поэтому нет возможности указать тип диска "eager" или "lazy".
Если вы используете виртуальный сетевой адаптер старой модели с пониженной пропускной способностью, например, Vlance, который показывает в гостевой ОС 10 Мбит/с - это не значит, что он будет работать на этой скорости. Он будет работать на скорости, максимально поддерживаемой физическим оборудованием и хостом ESXi.
С каждым днем все больше компаний выбирают в качестве основы своей ИТ-инфраструктуры облако в модели IaaS.
Самый важный этап в проектах перехода на облачную модель организации инфраструктуры является планирование, и при выборе IaaS-провайдера необходимо учесть множество факторов, об одном из которых мы хотели бы поговорить сегодня. Речь пойдет о правильном тестировании системы хранения данных...
Иногда бывает, что администратору платформы VMware vSphere требуется выгрузить список всех миграций vMotion виртуальных машин, которые произошли между хостами ESXi в последнее время, а также миграций Storage vMotion между хранилищами.
Для vMotion и SVMotion есть вот такой скрипт от Luc Dekens, который экспортирует миграции за указанное число часов или дней в файл XLS. Запустить его можно такой командой (скрипт точно работает для vSphere 6.5, как пишут здесь):
На выходе будет вот такая табличка (обратите внимание, что миграции поделены на пользовательские и системные от DRS/SDRS, а также в поле Type указано, что это - vMotion или SVMotion):
Также ребята из компании Opvisor несколько адаптировали этот скрипт в разрезе миграций хранилищ Storage vMotion для подсчета общего объема миграций и выложили его тут. Работа этого скрипта дает вот такой результат:
В апреле этого года компания VMware выпустила обновленную версию решения для создания отказоустойчивых кластеров хранилищ для виртуальных машин VMware vSAN 6.7. В этом продукте появилось несколько интересных возможностей, но наиболее наглядной стал переход на интерфейс Clarity UI, который позволяет организовать панели и визуальные элементы наиболее удобно для пользователя.
Служба vSAN performance service все еще является опциональной в кластере vSAN, однако уже содержит в себе ряд сервисов, играющих ключевую роль для мониторинга виртуальной инфраструктуры.
На каждом из серверов VMware ESXi служба vSAN performance service развертывается отдельно и позволяет независимо от сервера vCenter собирать данные о производительности кластера и предоставлять их внешним потребителям - CLI, PowerCLI, различным SDK и серверам vCenter:
Такая архитектура позволяет не создавать большой нагрузки на сервер vCenter, который бы в одиночку собирал и обрабатывал эти данные.
Данные о производительности собираются на уровне дисковых объектов, которым назначена определенная политика хранения (Storage Policy). Посмотреть эти объекты можно в разделе vSAN->Virtual Objects:
Так как сервис отслеживания производительности vSAN на хосте ESXi глубоко интегрирован с гипервизором, он позволяет получать метрики для всего стека работы с хранилищем на различных уровнях - виртуальной машины, хоста ESXi и кластера vSAN в целом.
В последней версии диски и дисковые группы были консолидированы в одну категорию, то есть можно посмотреть статистики по группе в целом, а также по отдельному физическому диску. Кроме того, можно смотреть информацию и об устройствах кэширования на хосте (buffer/cache device) в рамках дисковой группы:
В зависимости от того, какой вид просмотра группы или устройства вы выберете, будут доступны те или иные графики производительности. Например, для дисков хранения (capacity devices) будут показаны дополнительные графики "vSAN Layer IOPS" и "vSAN Layer Latency".
Также претерпели изменения разделы "VMkernel Adapters" и "VMkernel Adapters Aggregation" сетевых ресурсов хостов ESXi, которые были объединены в едином представлении Host Network:
Теперь можно выбрать просмотр агрегированных статистик по всем VMkernel адаптерам на хосте, либо выбрать отдельный адаптер. Надо помнить, что статистика по IO в данном разделе - это весь трафик VMkernel, а не только трафик vSAN (например, еще vMotion).
Кстати, интересно, что метрика packet loss, отображаемая как в формате, например, 23%o - это на самом деле не проценты, а так называемое permille-значение. То есть количество потерянных пакетов из одной тысячи (а не из ста, как в случае с процентами). Таким образом, 23%o соответствует значению 2.3% потерянных пакетов.
Еще одно полезное нововведение службы performance service в vSAN 6.7 - это возможность перестраивать размещение графиком в соответствии с разрешением экрана устройства. Например, на небольших устройствах графики будут идти последовательно вниз друг за другом, а на больших экранах показывается вот такой дэшборд:
Ну и последнее приятное улучшение - это возможность выбрать временной отрезок на любом графике и прозуммироваться в этот диапазон. Чтобы вернуться к изначальному представлению, надо нажать Zoom Out:
В графическом интерфейсе по управлению отказоустойчивым кластером VMware vSAN на платформе VMware vSphere отсутствует детальная информация о том, какая машина сколько физического пространства потребляет на уровне своих объектов (VMDK, vSWP и т.п.). Между тем, это может иногда оказаться полезным для администраторов, которые анализируют использование хранилищ и их рост.
Вильям Лам написал полезный PowerCLI-крипт, который позволяет такую статистику вывести - VSANVMDetailedUsage.ps1. Этот скрипт использует VSAN Management API, а в частности метод VsanQueryObjectIdentities() и свойство includeSpaceSummary.
Сценарий работает напрямую с хостом ESXi (поэтому надо предварительно установить переменные $ESXiHostUsername= "пользователь" и
$ESXiHostPassword = "пароль"), а в качестве входного параметра для функции Get-VSANVMDetailedUsage надо указать имя кластера vSAN.
Соответственно, использовать скрипт нужно так:
Get-VSANVMDetailedUsage -Cluster "VSAN-Cluster"
В результате вы получите подробную информацию обо всех виртуальных машинах кластера, их дисковых объектах, сколько места они занимают на диске фактически, а также сколько под них зарезервировано:
Кроме того, скрипт можно использовать и для просмотра информации по дисковым объектам конкретной ВМ, например, так:
RSS
